Authentication of Game Results

ABSTRACT

A gaming system includes a game server and a client server. The client server requests random numeric outcomes from the game server and supplies various state and game information. The game server generates one or more random numeric outcomes. The game server communicates the random numeric outcomes to the client server to be used in making a win determination. For purposes of future authentication, the game server stores a digitally-signed file that includes the random numeric outcomes and the state and game information.

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.10/308,603 filed Dec. 2, 2002 entitled “Authentication of Game Results.”

TECHNICAL FIELD OF THE INVENTION

This invention relates in general to games of chance, and moreparticularly to a gaming system that provides for authentication ofgenerated results.

BACKGROUND OF THE INVENTION

The gaming industry has enjoyed a substantial increase in popularityover the last decade. This increased popularity has produced anextremely competitive market for game operators.

Despite the increasingly competitive nature of the industry, a gameoperator responsible for paying out prizes may be unwilling to rely oninnovations developed by others if the game operator lacks the expertiseto understand the technology, its potential for error, and how it willimpact the game operator's prize obligations. Therefore, to facilitatethe introduction and acceptance of innovations into this competitivemarket, a system is desired that will shift responsibility for prizedisbursement to a game sponsor, typically the innovator, who is moreknowledgeable about the operation of the innovation and more capable ofpredicting and preventing its malfunction.

However, a system in which the game operator conducts the game but thegame sponsor is responsible for paying winners will encourage fraud bygame operators who can alter game situations to generate excessivewinners. Additionally, game sponsors may not want to be burdened withthe details of operating the game on their own. Consequently, a methodis desired for operating a game in which a game sponsor can agree toreimburse the game operator for all prizes disbursed, but be assuredthat the game operator will not fraudulently generate winners.

Additionally, game operators may choose to conduct a wide range ofgames. Thus, to prevent continual re-design, a system is desired thatallows a game sponsor to generate random results for a wide variety ofdifferent games conducted by multiple operators.

SUMMARY OF THE INVENTION

In accordance with the present invention, the disadvantages and problemsassociated with a gaming system have been substantially reduced oreliminated. In particular, the invention provides a method and systemfor providing random numeric outcomes to be used in determining whethera win has occurred in a game of chance, the method and system being bothflexible and fraudproof.

In accordance with one embodiment of the present invention, a method forproviding numeric outcomes to a game operator comprises receiving arequest that includes a game type of a game, game parameters, and commitdata describing the game; generating one or more random numeric outcomesusing the request; storing the commit data and the random numericoutcomes in an audit log; and communicating the random numeric outcomesto a game operator to be used by the game operator to determine whethera win has occurred.

In accordance with another embodiment of the present invention, a methodof authenticating a win result for a game of chance comprises receivinga claim regarding a win result in a game; retrieving an entry from anaudit log, the entry comprising one or more random numeric outcomes andcommit data associated with the game; verifying that the random numericoutcomes were generated properly; and using the commit data to verifythat the random numeric outcomes in the entry results in the win result.

Important technical advantages of certain embodiments of the presentinvention include the ability to authenticate win determinations made onthe basis of random numeric outcomes. Other important technicaladvantages of certain embodiments of the present invention includeproviding random numbers for a plurality of game operators and gamedevices, producing outcomes for a variety of games, and updating asignature key to provide a verifiable signature.

Additional technical advantages of the present invention will be readilyapparent to one skilled in the art from the following figures,description, and claims. Moreover, while specific advantages have beenenumerated above, various embodiments may include all, some, or none ofthe enumerated advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and itsadvantages, reference is now made to the following description, taken inconjunction with the accompanying drawings, in which:

FIG. 1 illustrates a system which includes a draw server, a clientserver, and at least one player;

FIG. 2 illustrates an outcome request according to one embodiment of thepresent invention;

FIG. 3 is a block diagram illustrating the contents and operation of adraw server;

FIG. 4 is a diagram illustrating operation of a draw module in producingan outcome from a request;

FIG. 5A is a diagram illustrating details about the operation of anaudit log memory;

FIG. 5B is a diagram illustrating further details about the operation ofan audit log memory;

FIG. 5C is a diagram illustrating further details about the operation ofan audit log memory;

FIG. 6 is a flowchart illustrating the operation of a draw server in oneembodiment of the present invention; and

FIG. 7 is a flowchart illustrating authentication of the results of agame.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates a gaming system 100 for playing a game of chance thatincludes a draw server 102, a client server 104, and players 112. Drawserver 102 couples to client server 104. Client server 104 is incommunication with players 112. Gaming system 100 can be adapted togenerate one or more random numeric outcomes 110 to be used in making awin determination for a wide range of games including, but not limitedto bingo, keno, and a variety of number-guessing games.

Draw server 102 and client server 104 can be general purpose computers,dedicated microprocessors, or other processing devices capable ofcommunicating electronic information. Examples of draw server 102 andclient server 104 include application-specific integrated circuits(ASICs), field-programmable gate arrays (FPGAs), digital signalprocessors (DSPs) and any other suitable specific or general purposeprocessors.

While FIG. 1 illustrates an embodiment of gaming system 100 includingone client server 104, gaming system 100 may include any number ofclient servers 104. Draw server 102 may generate random numeric outcomes110 for games conducted by multiple client servers 104.

Draw server 102 may couple to client server 104 in various ways. In aparticular embodiment, draw server 102 and client server 104 arephysically separated and draw server 102 couples to client server 104using an Internet connection. In another embodiment, draw server 102 andclient server 104 represent devices located in the same computer anddraw server 102 couples to client server 104 directly. In general, drawserver 102, client server 104, and players 112 may communicate using anycombination of public or private communications equipment such aselements of a public switched telephone network (PSTN), a globalcomputer network such as the Internet, a local area network (LAN), awide area network (WAN), or other appropriate wireline or wirelesscommunications equipment.

Client server 104 may conduct the game in real-time interacting withplayers 112 simultaneously, or interact with them individually over aperiod of time. Players 112 may interact with client server 104 locally,such as through a keyboard connected directly to client server 104, orremotely, such as through another computer that establishes a networkconnection with client server 104. Gaming system 100 can be adapted toconduct a game involving any number of players.

Numerous entities may control or operate the elements of gaming system100 and the entities may use a variety of different configurations todistribute the elements among themselves. In a particular embodiment, agame sponsor 150 and a game operator 160 operate or control draw server102 and client server, 104 respectively. Game sponsor 150 is a person,group of people, or entity responsible for disbursing prizes won ingames conducted on gaming system 100 or for reimbursing others whodisburse prizes. Game operator 160 is a person, group of people, orentity responsible for determining the winners of games conducted ongaming system 100.

In operation, client server 104 conducts a game for players 112. Clientserver 104 requests one or more random numeric outcomes 110 from drawserver 102 by communicating to draw server 102 an outcome request 106.Outcome request 106 includes game information that both indicates thetype of outcome requested from draw server 102 and describes the stateof the game for which client server 104 requests random numeric outcomes110.

For some types of games, players 112 may submit input before draw server102 generates random numeric outcome 110. For example, in a game ofkeno, players 112 may choose numbers upon which to wager before a randomnumeric outcome 110 can be requested from draw server 102. Other gamesmay not include input from players 112. For example, a bingo game canproceed with no input from players as the outcome is strictly a resultof the balls called and the bingo cards in play. For games with playerinput, the state information in outcome request 106 includes playerinput.

Draw server 102 receives outcome request 106 and, based on the gameinformation in outcome request 106, generates one or more random numericoutcomes 110. Draw server 102 creates an outcome file 108 containing therandom numeric outcomes 110 and digitally signs outcome file 108. Drawserver 102 stores a copy of outcome file 108 and communicates outcomefile 108 to client server 104.

Client server 104 then uses random numeric outcomes 110 in outcome file108 to generate a win determination based on the rules of the game andthe state. For example, if the game is bingo, client server convertsrandom numeric outcomes 110 in outcome request 108 into bingo balls anddetermines whether a win has occurred based on the bingo cards that arecurrently being played. For a keno game, client server 104 comparesrandom numeric outcomes 110 to the numbers players 112 bet to determineif a win occurred.

FIG. 2 illustrates further details of the contents of outcome request106. Outcome request 106 contains draw information that affects thegeneration of random numeric outcomes 110 by draw server 102 and gameinformation that describes both the current state of the game beingconducted and how client server 104 will use random numeric outcomes 110to make a win determination. Outcome request 106 can be an electronicfile, an electronic message or any other transferable collection ofinformation. Furthermore, although FIG. 2 illustrates an outcome request106 containing textual information, outcome request may containinformation in any format readable by draw server 102.

In a particular embodiment, this information includes a draw typeindicator 170, draw parameters 172, and commit data 174. However, inother embodiments, any or all of this information can be agreed tocontractually at the beginning of game operation and need not beincluded in outcome request 106.

Additionally, if draw server 102 communicates with a number of clientservers 104, outcome request 106 may include information identifying theparticular client server 104 that issued the request, a clientidentifier 176, and/or information identifying the particular game forwhich the client server 104 made the request, a game identifier 178.Draw server 102 may use client identifier 176 to determine theparticular client server 104 to send outcome file 108. Draw server 102may include game identifier 178 in outcome file 108 and client server104 may then use game identifier 178 to determine the particular gamefor which the random numeric outcomes 110 in outcome file 108 weregenerated.

Draw type indicator 170 specifies the general type of game for whichclient server 104 requests random numeric outcomes 110. For example, ifa particular draw server 102 supports bingo, keno, slot-machine, andnumber-guessing games, draw type indicator 170 specifies which of thesetypes of games client server 104 is conducting.

Draw parameters 172 give specific information about the draw beingrequested and may vary depending on the type of game client server 104conducts. For a keno game, this information may include the number ofnumbers to be generated. For a bingo game, this information may includethe number of balls to be drawn and the range of numbers available. Fora slot-machine game, this may include the number of reels being used andthe number of variations available on each.

Commit data 174 includes various additional information that defines thecurrent state of the game being conducted by client server 104 andindicates how client server 104 will use random numeric outcomes 110 tomake a win determination. The content of this information will varydepending on the characteristics of the particular gaming system 100,the requirements of the game being conducted, and the information gamesponsor 150 and game operator 160 have agreed upon contractually.

For example, for a slot machine game, commit data 174 may includeinformation indicating how client server 104 will convert the randomnumeric outcomes 110 into a slot symbol and what combination of symbolsare considered to be a winning result. For a keno game, commit data 174may include information indicating what numbers players 112 selected.For a bingo game, commit data 174 might include information indicatingwhat cards are currently in play. This information may be a copy of thebingo cards currently being played or card numbers referencing cardsgame operator 160 and game sponsor 150 have defined contractually.Similarly, commit data 174 may indicate whether the game being played isa basic bingo game or a “blackout” game requiring that all the squareson the card be covered.

Although this information may not be necessary to generate the requesteddraw, gaming system 100 prevents fraudulent claims by requiring gameoperator 160 to commit to this information before draw server 102generates random numeric outcomes 110. Absent commit data 174, gameoperator 160 could redefine the rules or state of the game afterreceiving random numeric outcomes 110 and generate fraudulent wins. Forexample, in a bingo game, if game operator 160 were not required tocommit to the specific bingo cards currently being played, game operator160 could simply claim the bingo cards in play included a card thatwould produce a winner based on random numeric outcomes 110.

The specific outcome request 106 illustrated in FIG. 2 applies to a kenogame in a particular embodiment. Draw type indicator 170 indicates thatclient server 104 requests a keno draw. Draw parameters 172 indicatethat client server 104 needs five balls and that the valid rangeincludes any number from “0” to “99”. Commit data 174 indicates thatplayers 112 have bet on the numbers “4”, “7”, “23”, “35”, “44”, and“73”.

FIG. 3 is a block diagram illustrating exemplary components of drawserver 102. Draw server 102 comprises a draw module 202, an interfacemodule 204, and an audit log memory 212.

Interface module 204 facilitates communication between draw module 202and client server 104. Additionally, interface module 204 stores a drawfile 208 created by draw module 202 in audit log memory 212 to preservedraw file 208 for future authentication.

Draw module 202 generates one or more random numeric outcomes 110 inresponse to outcome request 106 from client server 104, and returns drawfile 208 containing random numeric outcomes 110 and commit data 174.Additionally, draw module 202 digitally signs draw file 208 to allow forfuture authentication.

Interface module 204 and draw module 202 may comprise logic encoded inmedia for carrying out functions of the system. The logic comprisesfunctional instructions for carrying out programmed tasks. The mediacomprises computer disks or other suitable computer-readable media,application-specific integrated circuits (ASICs), field-programmablegate arrays (FPGAs), digital signal processors (DSPs) or other suitablespecific or general purpose processors, transmission media or othersuitable media in which logic may be encoded and utilized.

In one embodiment, draw module 202 comprises a dedicated processor suchas an IBM “4758” PCI Cryptographic Coprocessor. The “4758” is a PCIcomputer board for use in secure network communications and can beinstalled in most PCs. The “4758” generates random numbers based on anextremely sensitive reading of the temperature inside the “4758”. Aftergenerating random numbers, the “4758” digitally signs the results usinga 1024-bit private key in accordance with Federal Information ProcessingStandard 186 “Digital Signature Standard”.

Audit log memory 212 is a memory device for storing digitally-signeddraw files 208 communicated from draw module 202. Audit log memory 212can comprise any collection and arrangement of volatile or non-volatile,local or remote devices suitable for storing data, for example, randomaccess memory (RAM) devices, read only memory (ROM) devices, magneticstorage devices, optical storage devices, or any other suitable datastorage devices.

In operation, interface module 204 receives outcome request 106 fromclient server 104. In response, interface module 204 communicates a drawrequest 206 to draw module 202. Draw request 206 contains informationincluded in outcome request 106. Additionally, if outcome request 106includes client identifier 176 or game identifier 178, draw request 206may or may not include either or both of these depending on therequirements of gaming system 100.

Depending on the requirements of the particular client server 104 anddraw module 202, interface module 204 may format outcome request 106 toproduce draw request 206. By doing so, interface module 204 may make itfeasible to use otherwise incompatible components for client server 104and draw module 204, or to include a variety of different types ofclient servers 104 in gaming system 100. However, in a particularembodiment, interface module 204 may not need to do any formatting anddraw request 206 may be identical to outcome request 106.

In response to draw request 206, draw module 202 generates the requestedrandom numeric outcomes 110. Draw module 202 creates a draw file 208that is digitally signed and communicates draw file 208 to interfacemodule 204. Interface module 204 stores a copy of draw file 208 in auditlog memory 212, which may be used for future authentication.

Interface module 204 then communicates outcome file 108 to client server104. Outcome file 108 includes information contained in draw file 208.Outcome file 108 may or may not be digitally signed. As with outcomerequest 106 and draw request 206, interface module 204 may format drawfile 208 to create outcome file 108 depending on the requirements ofdraw module 202 and client server 104. However, in a particularembodiment, outcome file 108 is identical to draw file 208.

FIG. 4 is a block diagram illustrating exemplary components of drawmodule 202. Draw module 202 comprises a draw interface 300, a randomnumber generator 302, a signature generator 304, a key memory 306, andan anti-tampering device 309. Draw module 202 is enclosed in atamperproof casing 311.

Draw interface 300 receives draw request 206 from interface module 204and communicates draw request 206 to random number generator 302. Randomnumber generator 302 generates one or more random numeric outcomes 110based on draw type indicator 170 and draw parameters 172 in draw request206.

Random number generator 302 generates an unsigned draw file 314 whichincludes random numeric outcomes 110 and commit data 174. Commit data174 is included in unsigned draw file 314 to ensure that commit data 174is preserved for later authentication. Additionally, if draw request 106included client identifier 176 or game identifier 178, either or bothmay be included in unsigned draw file 314. Random number generator 302communicates unsigned draw file 314 to signature generator 304.

Signature generator 304 receives unsigned draw file 314 from randomnumber generator 302. Signature generator 304 reads a private key 308from key memory 306. Signature generator 304 uses private key 308 todigitally sign unsigned draw file 314 to generate draw file 208 with adigital signature 312. Draw interface 300 communicates draw file 208 todraw interface 300.

Draw interface 300, random number generator 302 and signature generator304 may comprise logic encoded in media for carrying out functions ofthe system. The logic comprises functional instructions for carrying outprogrammed tasks. The media comprises computer disks or other suitablecomputer-readable media, application-specific integrated circuits(ASICs), field-programmable gate arrays (FPGAs), digital signalprocessors (DSPs) or other suitable specific or general purposeprocessors, transmission media or other suitable media in which logicmay be encoded and utilized.

Key memory 306 holds private key 308 and a public key 310. Private key308 and public key 310 are a cryptographic key-pair generated bysignature generator 304 to sign and authenticate draw files 208 usingconventional techniques for digital signatures. Signature generator 304uses private key 308 to sign unsigned draw file 314. In accordance withconventional techniques, public key 310 can later be used to prove thatdraw file 208 was in fact signed using private key 308.

For purposes of verification, public key 310 can be read as needed fromkey memory 306 through draw interface 300. However, because drawinterface 300 does not provide access to private key 308 and becauseonly signature generator 304 can read private key 308, the value ofprivate key 308 is kept secret. Thus, proving that draw file 208 wassigned using private key 308 proves that only draw server 102 could havegenerated draw file 208 and draw file 208 is therefore authentic.

In a particular embodiment, signature generator 304 generates a newprivate key 308 and a new public key 310 periodically. In thisembodiment, draw module 202 stores old public keys 310 with draw file208 in the entry audit log 212. This feature enhances security of gamingsystem 100 by ensuring that private key 308 remains secret. Tamperproofcasing 311 may enclose draw module 202.

Tamperproof casing 311 can detect if tamperproof casing 311 is openedand can then erase the contents of key memory 306 or otherwise disabledraw module 202. This adds additional security to gaming system 100 bypreventing an individual from directly connecting external devices tokey memory 306 to read private key 308 or from altering the operation ofthe components of draw module 202.

Draw module 202 may include anti-tampering device 309. Anti-tamperingdevice 309 is capable of detecting or preventing unauthorized operationor alteration of draw module 202 and may represent a single component ormultiple components. Anti-tampering device 309 may be designed toprevent one or more potential types of tampering including, but notlimited to, electronic, magnetic, or physical tampering. Anti-tamperingdevice 309 may include heat, pressure, photoelectric, or magneticsensors; surge protectors; a tampering log to record suspicious changesin the physical environment; or any other device suitable to detect,prevent, expose, or record unauthorized operation or alteration of drawmodule 202. Anti-tampering device 309 may thwart unauthorized operationor alteration of draw module 202 or alleviate the impact of suchactivity by disabling all or any portion of draw module 202, bydocumenting the activity in a permanent log, by notifying game sponsor150, or by any other suitable means.

In a particular embodiment, draw server 102 comprises an IBM “4758” PCICryptographic Coprocessor. The “4758” includes anti-tampering devices309 that can detect temperature changes and X-ray exposure that mightaffect the circuitry of the “4758”. The anti-tampering devices 309 inthe “4758” prevent such attempts to alter the circuitry by erasing theprivate key 308 and public key 310 stored in key memory 306.

FIG. 5A illustrates further details of audit log memory 212 andoperation of audit log memory 212 during authentication of a winningclaim. FIG. 5 relates to an embodiment in which game operator 160possesses and operates both draw server 102 and client server 104. Inthis embodiment, game sponsor 150 is responsible for reimbursing gameoperator 160 for any prizes disbursed for winning results and, as aresult, game sponsor 150 authenticates any claim by game operator 160that a winning result has occurred.

Audit log memory 212 holds entries 350 which document operation of thedraw server 102 on a draw-by-draw basis. Each entry 350 includes a drawfile 208 from a draw conducted by draw server 102. An entry index 351 isassociated with each entry 350 to identify the particular game for whichdraw server 102 generated the included draw file 208. Entry index 351may represent game identifier 178 from draw request 206 or any otherinformation that can uniquely identify a game that received randomnumeric outcomes 110 from draw server 102. For gaming systems 100 thatinclude multiple client servers 104, entry index 351 may also includeclient identifier 176.

Additionally, in this embodiment, audit log memory 212 holds stored keys357 and associated key indices 358. Stored key 357 represents an expiredpublic key 310 that was in effect during a specified period in the past.A key index 358 indicates the time period over which the associatedstored key 357 was in effect.

FIG. 5B and 5C illustrate operation of audit log memory 212 duringauthentication of game results. When a winning claim is presented togame sponsor 150 by game operator 160, game sponsor 150 obtains auditlog memory 212. Game sponsor 150 verifies that audit log memory 212contains entries 350 and stored keys 357 for all the draws that havebeen conducted. If not, audit log memory 212 has been tampered with andany winning results are invalid.

Assuming audit log memory 212 contains a complete history of theoperation of draw server 102, game sponsor 150 locates the particularentry index 351 that corresponds to the game that produced the winningclaim, a contested entry index 354. Game sponsor 150 accesses the entry350 associated with contested entry index 354, a contested entry 362.Contested entry 362 represents the results of the contested game andincludes a contested draw file 363 containing a contested signature 364.

Similarly, game sponsor 150 locates the particular key index 358 thatcorresponds to the time period in which draw server 102 generatedoutcomes for the contested game, an authenticating key index 360. Gamesponsor 150 accesses the stored key 357 associated with authenticatingkey index 358, an authenticating key 359.

FIG. 5C illustrates authentication of the contested draw file 363. Gamesponsor 150 verifies that contested draw file 363 was in fact created bydraw server 102 and has been unaltered since creation. Morespecifically, game sponsor 150 verifies that authenticating key 359 isthe public key 310 associated with the private key 308 used to signcontested draw file 363 and that contested draw file 363 has not beenaltered since contested signature 364 was applied. This is done usingconventional digital-signature techniques in which game sponsor 150 usesauthenticating key 359, contested signature 364 and contested draw file363 as inputs to an authenticating algorithm 365. Authenticatingalgorithm 365 generates an affirmative response if draw server 102generated contested draw file 363 and contested draw file 363 has beenunchanged since being signed.

Once game sponsor 150 has proven that contested draw file 363 is in factvalid, game sponsor 150 verifies that contested draw file 363 produced awinning result. Specifically, game sponsor 150 applies random numericoutcomes 110 contained in contested draw file 363 to game and stateinformation provided by commit data 174 in contested draw file 363. Forexample, if contested draw file 363 corresponded to a draw for a bingogame, game sponsor 150 verifies that random numeric outcomes 110 wouldproduce a “bingo” based on the cards in play and the algorithm used forgenerating bingo balls from random numeric outcomes 110 as specified incommit data 174.

FIG. 6 is a flow chart illustrating the steps of generating a draw for agame of keno in one embodiment of the present invention. At step 410,draw server 102 receives from client server 104 an outcome request 106containing draw type indicator 170, draw parameters 172, and commit data174. Commit data 174 includes information indicating the numbers thatcurrently have bets. Draw server 102 formats outcome request 106 tocreate draw request 206 at step 420.

Using draw request 206, draw server 102 generates one or more randomnumeric outcomes 110 based on draw type indicator 170 and drawparameters 172 at step 430. At step 440, draw server 102 createsunsigned draw file 314 that includes the random numeric outcomes 110 andcommit data 174. The draw server 102 digitally signs unsigned draw file314 using private key 308 at step 450 creating draw file 208 withdigital signature 312. Draw server 102 saves a copy of the draw file 208to audit log memory 212 at step 460.

Draw server formats draw file 208 to create outcome file 108 at step470. At step 480, draw server 102 communicates outcome file 108 toclient server 104 for use in determining the winner of a game.

FIG. 7 is a flowchart illustrating the steps for authenticating theresults of a keno game under a particular embodiment of the presentinvention. FIG. 7 relates to one embodiment of the present invention inwhich a game operator 160 possesses and operates both client server 104and draw server 102.

In step 510, game sponsor 150 receives notice from game operator 160that a winning result has occurred in the keno game. Game sponsor 150obtains draw module 202 of draw server 102 in step 520.

Game sponsor 150 reads audit log memory 212 of the draw module 202 instep 530. In step 540, game sponsor 150 verifies that the audit logmemory 212 includes entries 350 for all the draws draw server 102 hasconducted. If not, the audit log memory 212 has been tampered with andthe results are invalid at step 550.

If audit log memory 212 does have all the entries 350, game sponsor 150locates entry index 351 that matches game identifier 178 of the gamewhich allegedly generated a win, contested entry index 354. Similarly,game sponsor 150 locates key index 358 that corresponds to the timeperiod in which draw server 102 generated random numeric outcomes 110for the contested game, authenticating key index 358. Using contestedentry index 354 and authenticating key index 358, game sponsor 150accesses, at step 560, contested entry 362 and authenticating key 359.In step 570, game sponsor 150 reads from the contested entry 362 acontested draw file 363 with contested signature 364.

Utilizing conventional digital signature techniques, game sponsor 150verifies in steps 580-600 that contested signature 364 was generatedwith a private key 308 associated with authenticating key 359. In step580, game sponsor 150 applies authenticating algorithm 365 to contesteddraw file 363, contested signature 364, and authenticating key 359 toverify that draw server 102 generated contested draw file 363 and thatcontested draw file 363 has been unchanged since being signed. If bothconditions are satisfied, at step 590, authenticating algorithm 365produces an affirmative response and the results are valid. However, ifeither condition is not satisfied, authenticating algorithm 365 does notproduce an affirmative response and the results are invalid at step 600.

If the results are valid, then at step 610 game sponsor 150 determineswhether contested draw file 363 would have created a winning resultbased on random numeric outcomes 110 and commit data 174 of contesteddraw file 363. Authentication results are shown at steps 620 and 630.

Although the present invention has been described with severalembodiments, a myriad of changes, variations, alterations,transformations, and modifications may be suggested to one skilled inthe art, and it is intended that the present invention encompass suchchanges, variations, alterations, transformations, and modifications asfall within the scope of the appended claims.

1. A method for providing numeric outcomes to a game operator,comprising: generating, by a processor, a random numeric outcome havinga digital signature, wherein the random numeric outcome is digitallysigned using a private key; verifying that the random numeric outcomehas not been changed since being generated; and communicating the randomnumeric outcome to a client server for determination of a game winner.2. The method of claim 1, wherein verifying that the random numericoutcome has not been changed since being generated comprises: retrievinga public key associated with the private key used to sign the randomnumeric outcome, wherein the public key indicates that the digitalsignature for the random numeric outcome was generated using theassociated private key; and verifying, based on the public key, that therandom numeric outcome has not been changed since being signed using theprivate key.
 3. The method of claim 2, wherein digitally signing therandom numeric outcome comprises digitally signing the random numericoutcome with a private key associated with a current time, and whereinretrieving the public key comprises: determining a time associated withthe random numeric outcome; and retrieving a public key associated withthe determined time.
 4. The method of claim 1, further comprising:storing the random numeric outcome in an audit log in an electronicmemory; after storing the random numeric outcome, retrieving the randomnumeric outcome from the audit log; and verifying that the randomnumeric outcome has not been changed since being stored.
 5. The methodof claim 4, wherein storing the random numeric outcome in the audit logcomprises storing the random numeric outcome in the audit log thatincludes a plurality of random numeric outcomes indexed by time.
 6. Themethod of claim 1, further comprising: receiving a draw request thatincludes a client identifier and commit data that defines conditionsunder which the random numeric outcome is to be generated; generating adraw file that includes the random numeric outcome, the clientidentifier, and the commit data; and verifying that the draw file hasnot been changed since being generated.
 7. The method of claim 6,further comprising: storing the draw file in an audit log in anelectronic memory, wherein the draw file is associated with an entryindex; after storing the draw file, retrieving the draw file from theaudit log; and verifying that the draw file has not been changed sincebeing stored.
 8. The method of claim 1, further comprising: receiving adraw request that includes a game identifier and commit data thatdefines conditions under which the random numeric outcome is to begenerated; generating a draw file that includes the random numericoutcome, the game identifier, and the commit data; and verifying thatthe draw file has not been changed since being generated.
 9. The methodof claim 1, further comprising: receiving a draw request that include agame type, game parameters, and commit data describing the game,wherein: the game type is selected from a group comprising keno, bingo,and slot-machine game types; and the game parameters vary depending onthe selected game type.
 10. The method of claim 1, wherein generating arandom numeric outcome comprises generating the random numeric outcomeaccording to an environmental input.
 11. A non-transitory computerreadable medium comprising logic for providing numeric outcomes to agame operator, the logic, when executed by a processor, operable to:generate a random numeric outcome having a digital signature, whereinthe random numeric outcome is digitally signed using a private key;verify that the random numeric outcome has not been changed since beinggenerated; and communicate the random numeric outcome to a client serverfor determination of a game winner.
 12. The non-transitory computerreadable medium of claim 11, wherein verifying that the random numericoutcome has not been changed since being generated comprises: retrievinga public key associated with the private key used to sign the randomnumeric outcome, wherein the public key indicates that the digitalsignature for the random numeric outcome was generated using theassociated private key; and verifying, based on the public key, that therandom numeric outcome has not been changed since being signed using theprivate key.
 13. The non-transitory computer readable medium of claim12, wherein digitally signing the random numeric outcome comprisesdigitally signing the random numeric outcome with a private keyassociated with a current time, and wherein retrieving the public keycomprises: determining a time associated with the random numericoutcome; and retrieving a public key associated with the determinedtime.
 14. The non-transitory computer readable medium of claim 11,wherein the logic is further operable to: store the random numericoutcome in an audit log in an electronic memory; after storing therandom numeric outcome, retrieve the random numeric outcome from theaudit log; and verify that the random numeric outcome has not beenchanged since being stored.
 15. The non-transitory computer readablemedium of claim 14, wherein storing the random numeric outcome in theaudit log comprises storing the random numeric outcome in the audit logthat includes a plurality of random numeric outcomes indexed by time.16. The non-transitory computer readable medium of claim 11, wherein thelogic is further operable to: receive a draw request that includes aclient identifier and commit data that defines conditions under whichthe random numeric outcome is to be generated; generate a draw file thatincludes the random numeric outcome, the client identifier, and thecommit data; and verify that the draw file has not been changed sincebeing generated.
 17. The non-transitory computer readable medium ofclaim 16, wherein the logic is further operable to: store the draw filein an audit log in an electronic memory, wherein the draw file isassociated with an entry index; after storing the draw file, retrievethe draw file from the audit log; and verify that the draw file has notbeen changed since being stored.
 18. The non-transitory computerreadable medium of claim 11, wherein the logic is further operable to:receive a draw request that includes a game identifier and commit datathat defines conditions under which the random numeric outcome is to begenerated; generate a draw file that includes the random numericoutcome, the game identifier, and the commit data; and verify that thedraw file has not been changed since being generated.
 19. Thenon-transitory computer readable medium of claim 11, wherein the logicis further operable to: receive a draw request that include a game type,game parameters, and commit data describing the game, wherein: the gametype is selected from a group comprising keno, bingo, and slot-machinegame types; and the game parameters vary depending on the selected gametype.
 20. The non-transitory computer readable medium of claim 11,wherein generating a random numeric outcome comprises generating therandom numeric outcome according to an environmental input.
 21. A systemfor providing numeric outcomes to a game operator, comprising: a randomnumber generator operable to generate a random numeric outcome having adigital signature, wherein the random numeric outcome is digitallysigned using a private key; a digital signature generator operable toverify that the random numeric outcome has not been changed since beinggenerated; and an interface module operable to communicate the randomnumeric outcome to a client server for determination of a game winner.22. The system of claim 21, wherein the digital signature generator isfurther operable to: retrieve a public key associated with the privatekey used to sign the random numeric outcome, wherein the public keyindicates that the digital signature for the random numeric outcome wasgenerated using the associated private key; and verify, based on thepublic key, that the random numeric outcome has not been changed sincebeing signed using the private key.
 23. The system of claim 21, furthercomprising: an audit log memory operable to store the random numericoutcome; and the digital signature generator is further operable to:retrieve the random numeric outcome from the audit log; and verify thatthe random numeric outcome has not been changed since being stored. 24.The system of claim 23, wherein the audit log memory is operable tostore a plurality of random numeric outcomes indexed by time.
 25. Thesystem of claim 21, wherein: the interface module is further operable toreceive a draw request that includes a client identifier and commit datathat defines conditions under which the random numeric outcome is to begenerated; the random number generator is further operable to generate adraw file that includes the random numeric outcome, the clientidentifier, and the commit data; and the digital signature generator isfurther operable to verify that the draw file has not been changed sincebeing generated.
 26. The system of claim 25, further comprising: anaudit log memory operable to store the draw file, wherein the draw fileis associated with an entry index; and the digital signature generatoris further operable to: retrieve the draw file from the audit log; andverify that the draw file has not been changed since being stored. 27.The system of claim 21, wherein the system is enclosed in a compartmentoperable to disable the signature generator upon breach of thecompartment.
 28. The system of claim 21, wherein: the interface moduleis further operable to receive a draw request that includes a gameidentifier and commit data that defines conditions under which therandom numeric outcome is to be generated; the random number generatoris further operable to generate a draw file that includes the randomnumeric outcome, the game identifier, and the commit data; and thedigital signature generator is further operable to verify that the drawfile has not been changed since being generated.
 29. The system of claim21, wherein the interface module is further operable to receive a drawrequest that include a game type, game parameters, and commit datadescribing the game, wherein: the game type is selected from a groupcomprising keno, bingo, and slot-machine game types; and the gameparameters vary depending on the selected game type.
 30. The system ofclaim 21, wherein the a random number generator is further operable togenerate the random numeric outcome according to an environmental input.31. A non-transitory computer readable medium comprising logic forproviding numeric outcomes to a game operator, the logic, when executedby a processor, operable to: receive a draw request that includes commitdata that defines conditions under which random numeric outcomes to begenerated will result in a win for a player of a game; generate, with anelectronic processor, a random numeric outcome based on the drawrequest; communicate the random numeric outcome to a game operator to beused by the game operator to determine whether a win has occurred in thegame; generate a draw file that includes the random numeric outcome andthe commit data; digitally sign the draw file with a digital signatureusing a private key; store the draw file in an audit log in anelectronic memory; after storing the draw file, retrieve the draw filefrom the audit log; verify that the draw file has not been changed sincebeing stored, wherein verifying that the draw file has not been changedsince being stored comprises: retrieve a public key associated with theprivate key used to sign the draw file, wherein the public key indicatesthat the digital signature for the draw file was generated using theassociated private key; and verify, based on the public key, that thedraw file has not been changed since being signed using the private key;and confirm, based on information in the draw file, that the randomnumeric outcome resulted in a game win.
 32. The non-transitory computerreadable medium of claim 31, wherein digitally signing the draw filecomprises digitally signing the draw file with a private key associatedwith a current time, and wherein retrieving the public key comprises:determining a time associated with the draw file; and retrieving apublic key associated with the determined time.
 33. The non-transitorycomputer readable medium of claim 31, wherein storing the draw file inan audit log comprises storing the draw file in an audit log thatincludes a plurality of draw files indexed by time.
 34. Thenon-transitory computer readable medium of claim 31, wherein receiving adraw request further comprises receiving a draw request that includesgame parameters and the game parameters describe parameters for one ormore random numeric outcomes to be generated.
 35. The non-transitorycomputer readable medium of claim 31, wherein receiving a draw requestfurther comprises receiving a draw request that includes a game type andthe game type is selected from a group comprising keno, bingo, andslot-machine game types.
 36. The non-transitory computer readable mediumof claim 31, wherein retrieving the draw file comprises: receiving anindication that a random numeric outcome included in the draw fileresulted in a game win; and in response to receiving the indication,retrieving the draw file from the audit log.